Medicare and numerous other payers have recently converted their reimbursement mechanism to the "prospective payment system". This payment mechanism utilizes diagnosis-related groups, commonly known as "DRG's" to determine the level of hospital payments. Conceptually, DRG's cluster patients to economically homogenous groups, i.e. cases that require comparable resources for their care and that therefore are to receive identical fixed payments. DRG's are assigned by a complex federally-mandated computer program and based upon "case complexity" as conveyed through the configuration of diagnoses reported and/or procedures performed during the course of the hospital stay.
It is the hospital's obligation under federal law to file valid claims statements in seeking compensation for services provided under federal beneficiary programs. Under the DRG-based prospective payment system, the validity of claims statements is dependent upon an appropriate description of case complexity and compliance with reporting requirements since both can affect the DRG assignment and thus the payment received.
There are several tasks that must be performed to enable a hospital to submit an appropriate claim statement for any given case. First, the responsible physician must record and substantiate each diagnosis and procedure term that is relevant to the case, these terms must then be coded in compliance with coding guidelines and reported in compliance with definitional data requirements.
Failure to comply with the conditions described above expose the hospital to two main risks: the risk of inappropriate financial loss and the risk of incurring penalties for misreporting. If the physician fails to describe fully and accurately (and also to document properly) the diagnostic complexity of the case or the full extent of procedural interventions actually performed, the hospital is likely to be inappropriately underpaid. If the diagnosis and/or procedure are inappropriately coded or are otherwise not in compliance with definitional and reporting requirements, the hospital faces potential penalties for filing false claims.
Because data requirements, coding guidelines and reporting rules vary in regard to their specificity, their relevance to the given case, and also with respect to the consequences of non-compliance, the risks which the hospital actually faces can vary in severity from minor to major. Consequently, judgments often must be made as to whether a given case poses risks that are serious enough to warrant the investment of resources necessary to undertake an in-depth case review.
Since there is a strong linkage between the risk of inappropriate financial loss and clinical descriptions of the case in the medical record (i.e. diagnostic and procedural terms recorded), it is appropriate to refer primarily to physicians cases that are at risk of potential financial loss. Because coding practices and definitional requirements are directly linked to misreporting, it is appropriate to refer primarily to coders cases that are at risk of potential penalties.
As previously described, valid DRG-assignments are dependent upon accurate and substantial descriptions of the complexity of a patient's clinical status as documented in the medical record, precise descriptions of procedures performed during the hospital stay, and compliance with established data requirements and coding guidelines in the reporting of hospital claims data.
Consequently, there are two main tasks for third party reviewers such as payers or peer-review organizations to undertake in order to determine whether claims statements that hospitals submit for payment under the DRG-based prospective payment are valid or not.
It is typical of third party organizations responsible for determining the validity of DRG assignments that there is a formal division of responsibility in conducting the record review and data validation process. Typically, case review is initiated by a "review coordinator", usually a nurse. Based upon what is found in the record, the reviewer decides whether there is reason to question the validity of data reported on the payment claim. Cases in which the accuracy of coding is questioned are referred to coding experts or data specialists for final action. In the event that the clinical validity of diagnostic or procedure terms or the adequacy of substantiating documentation is at question, cases of this type are referred to a physician reviewer for final action. Since there is a clear-cut division of responsibility for dealing with clinical as opposed to coding issues, the efficiency of case based review activities is dependent upon routing problem cases to the review personnel who have assigned responsibility for them.
Finally, there is the added dimension that third party review organizations are also responsible for detecting systematic problems in data quality or reporting biases that result in systematic overpayments to hospitals or other care providers. By generating performance profiles from aggregated data, systematic problems in data quality can be detected and related to causative factors. Comparative analyses can be performed across hospitals (and/or other care providers) to establish rational priorities for future in-depth review activities, i.e. to indicate where the investment of personnel and resources would be most productive.
Because there are so many federally-mandated rules and regulations that define the accuracy and validity of diagnosis and procedure terms reported on hospital claims forms subject to the prospective payment system, there is a need for a computer-assisted process designed to promote compliance with these rules and regulations that define the quality of hospital claims data.
The U.S. Pat. No. 4,491,725 to Pritchard discloses a medical insurance verification and processing system which Verifies a patient's insurance coverage, electronically files a claim, converting claim codes as necessary such that the claim is sent to the correct insurance company with the correct claim codes, ensuring the claim will provide payment appropriate for the treatment claimed.
The U.S. Pat. No. 4,667,292 to Mohlenbrock discloses "a computer system for identifying the most appropriate of the billing categories . . . prescribed by a government entity as a basis for determining the amount that health care providers, such as hospitals, are to be reimbursed . . . ". The system includes a process by which billing categories generated by diverse techniques "can be compared by the computer system, . . . if they agree, a high degree of confidence exists in the (selected category) . . . if they disagree,. it is known that a reconciliation must be made . . . this assists the hospital to obtain the maximum reimbursements to which it is entitled."
The U.S. Pat. No. 4,700,297 to Hagel , Sr. discloses a relocation management reporting system which "upon entry of a request for reimbursement the data and expenses category are verified and (stored data) is retrieved and processed to authorize or reject the . . . request."
The U.S. Pat. No. 4,857,713 to Brown discloses "A hospital error-limiting program . . . directed primarily at reduction of hospital errors in delivery of medications, goods, services, or procedures in patient treatment . . . "
The U.S. Pat. No. 4,858,121 to Barber discloses a computerized medical payment system which includes patient, doctor, and carrier verification, and error trapping.
The U.S. Pat. No. 4,591,974 to Dornbush is of a more general interest.
Other Products: Several software products have been or currently are being marketed that deal in a more direct manner with the impact of data reporting on DRG assignments and hospital claims payments than does any of the above-described patented systems. Taken as a group, these newer products share in common a DRG Grouper, files containing diagnoses and procedure codes, files containing defined data error conditions, and a mechanism for generating messages when error conditions are detected in hospital claims data through data edit checks. Some of these products generate a patient data base while others do not. A few generate worksheets to facilitate coder-oriented case review but others do not. The product that methodologically is closest in resemblance to the method and system that is the subject of this application is the Patient Data Quality Manager (PDQM) which was developed by the assignee of this application.
The Patient Data Quality Manager (PDQM) is defined as an integrated set of menu-driven executable computer programs designed to manage the process of improving the quality and accuracy of reportable hospital claims data. It is a stand-alone, microcomputer-based system for processing data quality edits interactively for individual patients.
The principal function served by the PDQM is that of data quality assurance. This function is implemented through a series of interactive transactions supported by an extensive set of Data Quality edits. After the claims data for a given case are key entered into the system, a command is given to run the data quality checks. At the completions of the data quality checking process, any messages generated are displayed on the computer screen. A decision is then made as to whether worksheets are to be generated and printed (in real time or later) to facilitate the human aspect of the data correction process including review of data in the medical record or asking clinicians to provide data not previously recorded.
Worksheets: Two different types of worksheets can be generated: one is formatted to serve the functional needs of data specialists and the other is formatted to facilitate communication with physicians. However, the system operator must personally select the message(s) to be displayed on either type of worksheet.
For example, if a given problem in data quality arises from technical coding issues that can be addressed by the data specialist, a Coding Worksheet can be generated and the system operator selects from a menu the specific message(s) that is (are) to be printed on the worksheet. If the system operator decides that a given data quality message involves clinical judgment or requires additional input from the physician, a Physician Data Quality Worksheet can be generated and the message(s) similarly selected to be displayed on it.
The system is also capable of generating and tracking the Attestation Document that Medicare requires attending physicians to sign for the purpose of verifying claims data. The content of this document is standardized nationwide and contains no data quality messages.
Support Functions: Secondary functions support the logistics of the data correction process, a component of the overall process of improving the quality of reportable hospital claims data. Among the logistic support features of the PDQM are the following:
interactive data entry functions, PA1 a data base system containing patient claims data and identifier information on data specialists and physicians, PA1 a data archive program that transfers data from closed cases to diskettes for user-selected time periods, PA1 certain utility programs that implement user-selected data display options and data base managers to support the basic function of data correction and file maintenance. PA1 DRG Group programs, PA1 ICD-9-CM diagnostic and procedure codes and titles, PA1 revised ICD-9-CM codes and titles, PA1 other reportable data elements necessary for assigning DRGs, and PA1 Medicare edit checks. PA1 Automated screening of groups of cases (batch mode) to determine the hospital's risk of potential financial loss and the risk of penalty; PA1 Selectively sorting the problems detected as to their seriousness or priority; PA1 The generation of appropriate messages that describe both problems in data quality and their solutions in comprehensive terms; and PA1 Selectively printing on worksheets messages that are appropriate to the individuals responsible for resolving the problems. PA1 aggregation of the data quality status reports for a whole group of cases; PA1 classification of detected data quality problems as to the nature of the risk to which the hospital is exposed (i.e. financial loss vs. penalty), PA1 generation of summary profile reports that characterize the distribution of data quality problems by type, severity and source in a format suitable for recognizing patterns of systematic data quality problems and suitable also for monitoring the results of the hospital's data correction process. PA1 Automated screening of grounds of cases (batch processing mode) to determine the likelihood of invalid claims reporting on the basis of unsubstantiated clinical descriptors of case complexity and/or non-compliance with established reporting requirements and coding guidelines. PA1 Selectively sorting the problems detected as to their seriousness or priority. PA1 Generation of messages that describe the nature of the data quality problem detected and cite the documentary evidence needed to validate (or invalidate) the data as reported. PA1 Printing messages on worksheets that are appropriate to the professional status of the reviewer(s) responsible for making a determination of data validity. PA1 Transferring of patient data sets from host computer to portable computer in the event that interactive on-site record reviews are to be conducted in hospitals. PA1 Aggregating data quality status for groups of cases. PA1 Classifying the data quality problems detected as to their likely cause or source. PA1 Generating a summary profile report that characterizes the likely causes or sources of problems in data quality detected in the group of cases processed. The report format is suitable for providing feedback to the hospital (or care provider) and also for prioritizing future review activities. PA1 Generating a more focused report in a format designed to detect and quantify systematic reporting bias that results in inappropriately increased payments to the hospital or other care provider.
While the preponderance of data quality edits contained in the PDQM are proprietary as are all support programs, the program utilizes as sub-routines a number of resources belonging initially to the public domain. Among these are:
A set of security features is also built into the PDQM to protect the confidentiality of patient data.
Log Control Reports: There are several logistic support case listings ("logs") that resemble "tickler" files and contain data essential to determine whether data correction steps for each case have been completed or not or whether there are outstanding data quality worksheets. Other listings are used to assign review cases to specific case review personnel, etc.
In spite of the fact that the PDQM contains a more extensive set of data quality messages and more optional features than is offered by any known competing products, this software package has not been well received in the marketplace and only a few installations have occurred. Many enhancements and user options have been added over a six-year period without materially affecting its marketability. There has also been a relatively high contract cancellation rate for installed systems.
Based on a recent survey of former users, it has been determined the design configuration of the PDQM is flawed. While the intent was to reduce a hospital's risk to both penalties and inappropriate financial losses due to the misreporting of case data, no provisions were made in the PDQM to distinguish one from the other. All messages addressed issues of data quality without classifying them as to reporting risk potential. Neither was any means offered to prioritize cases on the basis of the seriousness of the potential consequences of various types of misreporting. Similarly, while it was also the intent that messages pertaining to inappropriate coding should be transmitted only to data specialists and messages pertaining to clinical documentation problems should be transmitted only to physicians, no built-in mechanism was provided in the PDQM to selectively route these messages to their proper destinations. Message selection was left to operator judgment. Other major deficiencies of the PDQM are that its stand-alone design resulted in duplicated data entry problems for hospitals and its lock-step, operator-dependent, interactive processing of case data was inefficient, resulting in billing delays.